An object, in the framework of object-oriented computer programming, is an instance of a class that includes pieces of code called data and methods. Typically, the methods operate on private data, also called instance data, that the object owns. Objects provide a programming paradigm for creating intelligent software that mirrors physical things. Objects exhibit three properties that make them incredibly useful: encapsulation, inheritance, and polymorphism. Encapsulation means the object's implementation is hidden from public view. Inheritance is the passing of class resources or attributes from a parent class downstream in a class hierarchy to a child class. Polymorphism means identical methods located in different objects can act differently.
As shown in block diagram form in FIG. 1, traditional classes 100 include data and methods. However, control information 102, which is part of the code embodied in a computer program application, is not directly associated with the class, as illustrated by the control infornation's disassociation from the class 100.
FIG. 3 illustrates one form of control information 102 (FIG. 1). The three ovals 110 represent the different data states an object of a particular class experiences during execution of application program code. "State" is the cumulative results of the behavior of an object, wherein at any given point in time, the state of an object encompasses all of the (usually static) properties of the object plus the current (usually dynamic) values of each of these properties. A minimum of one data state is required for describing control information. The arrowed lines 112 connecting the data state ovals 110 indicate state transitions which include a transition method(s) executed when a specified data condition(s) is met. A state may have a single state transition or multiple unique transitions to other states. Essentially, the state diagram, FIG. 3, is an abstract representation of object operation as determined by the underlying application program code.
Despite object usefulness, in the past, abstract notions such as state-based control have not been directly related to objects (FIG. 1). In the past, state-based control has been created at the application program code level by a highly skilled programmer.
Software is available for allowing a user to easily define data without requiring the user to know the particulars of the programming code, such as C++, of the objects. The proper code is generated according to user entered object information. However, the objects created must still rely on the state-based control programmed in the application program code. In the past, there existed no easy way to create new objects or edit old objects that execute state-based control different than that programmed in the application program code. Therefore, in order to change or create state-based control, reprogramming, or adding to, the original application program code was required.
Likewise, distributed objects, e.g., objects defined by data and methods used in client/server environments, have state-based control embedded within the application program code. An object-oriented messaging system, such as Object Management Group's Common Object Request Broker Architecture (CORBA) or Microsoft's Component Object Model (COM), provides management of distributed objects on heterogeneous client/server networks. Essentially, distributed objects are either on a client or a server's side of the network. Application programmers build a main routine/application program code for controlling execution flow and for coding client distributed objects to request service from static server distributed objects. The messaging system detects clients' object requests and passes these requests to a server object that, in turn, performs the service and responds to the client with a result. Unfortunately, the client/server approach described above fails to give objects any abstract notion of behavior or control, forcing the programmer to develop the complex finite state-based control code required to manage the use of any object used in the client/server network. For example, there is currently no way a standard C++ object can be defined to launch a remote event handler routine when its data elements match a certain state without the programmer explicitly coding in the state and transition data conditions in the main application program code for monitoring the object's data for a match condition. In other words, manipulation of finite state-based control is hidden from a creator of personalized objects unless the creator is gifted with the programming knowledge to manipulate state-based control in the application program code. Creation of distributed objects and related control is still essentially a programmer's job. A non-programming type client/server manager must understand programming code in order to change the finite state-based control behavior of an object. A simple to use interface for personalizing or changing objects with object specific finite state-based control behavior does not exist.
The present invention is directed to overcoming the foregoing and other disadvantages. More specifically, the present invention is directed to providing a method and apparatus for easily generating executable code for objects with finite state-based control behaviors.